-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JS/TS package acquisition #182801
JS/TS package acquisition #182801
Conversation
We actually want webpack to emit commonjs, but need to write ES default imports to use node-maintainer
Thank you for the PR. Just testing it out. A few blockers on merging this even in an experimental state:
|
I did not check in |
This includes the executable files node_maintainer.js and node_maintainer_bg.wasm. I had to skip linting on this commit because node_maintainer.js does not follow vscode standards.
I've copied this PR over to #184438. This should unblock the yarn.lock check |
This PR packages @zkat's work to enable package acquisition on the web. This is broken into 3 parts:
npm
replacement. But it could be something much simpler and hackier if we want to avoid shipping a large WASM bundle at first. See packageManager.ts; the associated README has instructions on how to install orogene; I didn't include it in this PR yet although Kat intends for it to be vendored eventually.node_modules
that, when accessed, use the npm replacement to install packages and cache them. The extension's tsserver web host changes slightly to use the third filesystem as a fallback for paths containingnode_modules
. This should avoid errors onimport
s in TS files, but will also help both TS and JS intellisense.The only thing I've done to zkat's work is to merge from main and fix the extension's tsconfigs so they can correctly load WASM bundles without having to switch to ES modules. (thanks @andrewbranch for helping me with this)
As far as I can tell, the current status of this code is: working end-to-end for a demo scenario, with a variety of bugs blocking other scenarios. For example, after I got the code to build and run, when I tried to load a project from a local disk, I got errors about missing files in the virtual filesystem. My guess is that most of the bugs are minor and that there are two or three major ones lurking.
The design could probably use some work as well, but I believe it's good enough to check in and start iterating on.
Here are the remaining TODOs from the prototype PR: